.github/workflow: Add auto release publish workflow - #11661

I would strongly encourage we consider using the release notes automatically generated by GitHub. It already nicely lists all the changes included since the previous release; automatically tagging contributors and relevant PRs. Ex: https://github.com/aws/s2n-tls/releases/tag/v1.6.1

Based on the docs, it's extensible/configurable as well.

@j-xiong I think we start to sign the tarball, can you share how it works in the current release process?

@shijin-aws A few steps I took:

Do once:

• Generate a new key-pair: gpg --gen-key.
• Send the key to a key server: gpg --keyserver hkp://keyserver.ubuntu.com:80 --keyserver-options http-proxy="$http_proxy" --send-keys <key>
• Export the public key: gpg --armor --export jianxin.xiong@intel.com >public_key.asc.

For every release:

• Sign the release tarball: gpg --armor --detach-sign libfabric-<version>.tar.bz2

@shijin-aws A few steps I took:

Do once:

* Generate a new key-pair:  `gpg --gen-key`.

* Send the key to a key server: `gpg --keyserver hkp://keyserver.ubuntu.com:80 --keyserver-options http-proxy="$http_proxy" --send-keys <key>`

* Export the public key: `gpg --armor --export jianxin.xiong@intel.com >public_key.asc`.

For every release:

* Sign the release tarball: `gpg --armor --detach-sign libfabric-<version>.tar.bz2`

How do you import the private key when signing the tarball for every release? It is always operated on a persistent server which already has the key imported?

I may drop that signing procedure within the current scope of this PR.. Every publisher can choose their own signing approach during the publish. It will just generate a draft release page and the operator can add/edit the artifacts anyway

@shijin-aws I was doing it on a specific server, but I believe there are gpg commands to export and import private keys as well.

@shijin-aws I was doing it on a specific server, but I believe there are gpg commands to export and import private keys as well.

But you have to pull the private key from a server to import if you want to sign the tarball from the github action container?

@shijin-aws I agree the signing can be done manually.

I would strongly encourage we consider using the release notes automatically generated by GitHub. It already nicely lists all the changes included since the previous release; automatically tagging contributors and relevant PRs. Ex: https://github.com/aws/s2n-tls/releases/tag/v1.6.1

Based on the docs, it's extensible/configurable as well.

Good suggestion, we can make it as a follow-up PR

I would strongly encourage we consider using the release notes automatically generated by GitHub. It already nicely lists all the changes included since the previous release; automatically tagging contributors and relevant PRs. Ex: https://github.com/aws/s2n-tls/releases/tag/v1.6.1
Based on the docs, it's extensible/configurable as well.

Good suggestion, we can make it as a follow-up PR

Oh, I didn't realize this will be just a button-click during the release publishing

Addressed all the comments. @j-xiong @aingerson An example of the release page created by this workflow is available in https://github.com/shijin-aws/libfabric/releases/tag/v2.5.0sjina1.0. It is triggered by merging shijin-aws#14. Please let me know if you have more comments, thank you!

bot:aws:retest